Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MaybeUninit::copy/clone_from_slice #79607

Merged
merged 1 commit into from
Dec 16, 2020

Conversation

beepster4096
Copy link
Contributor

This PR adds 2 new methods to MaybeUninit under the feature of maybe_uninit_write_slice: copy_from_slice and clone_from_slice.

These are useful for initializing uninitialized buffers (such as the one returned by Vec::spare_capacity_mut for example) with initialized data.

The methods behave similarly to the methods on slices, but the destination is uninitialized and they return the destination slice as an initialized slice.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cramertj (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 1, 2020
@m-ou-se m-ou-se added A-raw-pointers Area: raw pointers, MaybeUninit, NonNull T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Dec 1, 2020
@m-ou-se m-ou-se assigned m-ou-se and unassigned cramertj Dec 1, 2020
Copy link
Member

@m-ou-se m-ou-se left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Looks like a useful addition, especially in combination with Vec::spare_capacity_mut.

I'm wondering if the names of these functions should be different. The new copy_from_slice is mostly equivalent to [T]::copy_from_slice, but [T]::clone_from_slice drops old values whereas this new one doesn't. Maybe it should use write in the name, to make clear it behaves like MaybeUninit::write or ptr::write. What do you think?

library/core/src/mem/maybe_uninit.rs Show resolved Hide resolved
library/core/src/mem/maybe_uninit.rs Show resolved Hide resolved
library/core/src/mem/maybe_uninit.rs Outdated Show resolved Hide resolved
library/core/src/mem/maybe_uninit.rs Outdated Show resolved Hide resolved
///
/// [`clone_from_slice`]: MaybeUninit::clone_from_slice
/// [`slice::copy_from_slice`]: ../../std/primitive.slice.html#method.copy_from_slice
#[unstable(feature = "maybe_uninit_write_slice", issue = "none")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to open a tracking issue, and then add its number here.

@beepster4096
Copy link
Contributor Author

I'm wondering if the names of these functions should be different. The new copy_from_slice is mostly equivalent to [T]::copy_from_slice, but [T]::clone_from_slice drops old values whereas this new one doesn't. Maybe it should use write in the name, to make clear it behaves like MaybeUninit::write or ptr::write. What do you think?

Maybe write_slice and write_slice_cloned?

Copy link
Contributor

@poliorcetics poliorcetics left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Welcome and thanks for the PR !

library/core/src/mem/maybe_uninit.rs Outdated Show resolved Hide resolved
library/core/src/mem/maybe_uninit.rs Show resolved Hide resolved
library/core/src/mem/maybe_uninit.rs Outdated Show resolved Hide resolved
library/core/src/mem/maybe_uninit.rs Outdated Show resolved Hide resolved
library/core/src/mem/maybe_uninit.rs Show resolved Hide resolved
library/core/src/mem/maybe_uninit.rs Outdated Show resolved Hide resolved
@cramertj
Copy link
Member

cramertj commented Dec 8, 2020

r? @sfackler

@rust-highfive rust-highfive assigned sfackler and unassigned m-ou-se Dec 8, 2020
@bors
Copy link
Contributor

bors commented Dec 10, 2020

☔ The latest upstream changes (presumably #79621) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

@beepster4096 beepster4096 force-pushed the maybe_uninit_write_slice branch from 74dbaec to 125ca5b Compare December 10, 2020 20:42
@sfackler
Copy link
Member

r=me with a tracking issue

@m-ou-se
Copy link
Member

m-ou-se commented Dec 11, 2020

Maybe write_slice and write_slice_cloned?

Sounds good. That should make it a bit clearer that they only write, and don't drop old elements like []::clone_from_slice does.

Can you squash the commits?

@beepster4096 beepster4096 force-pushed the maybe_uninit_write_slice branch 2 times, most recently from 7024d7f to 87522c4 Compare December 12, 2020 03:44
@beepster4096
Copy link
Contributor Author

Squashed and renamed.

@m-ou-se
Copy link
Member

m-ou-se commented Dec 12, 2020

Can you open a tracking issue for this, and put its number in the #[unstable] attributes? Then we can merge this. :)

@beepster4096
Copy link
Contributor Author

Added tracking issue of #79995 to the attributes

@m-ou-se
Copy link
Member

m-ou-se commented Dec 14, 2020

Thanks!

@bors r+

@bors
Copy link
Contributor

bors commented Dec 14, 2020

📌 Commit 5873f9f5b00401c50d723374922bb4511e86cc3b has been approved by m-ou-se

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Dec 14, 2020
@m-ou-se m-ou-se assigned m-ou-se and unassigned sfackler Dec 14, 2020
@bors
Copy link
Contributor

bors commented Dec 14, 2020

⌛ Testing commit 5873f9f5b00401c50d723374922bb4511e86cc3b with merge b9e30d31972a1f45e6a7e3f6c412e2ac1e6abd61...

@bors
Copy link
Contributor

bors commented Dec 14, 2020

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 14, 2020
@m-ou-se
Copy link
Member

m-ou-se commented Dec 14, 2020

The uninit_write_slice_cloned_mid_panic test failed on wasm, probably because unwinding is not available and panic::catch_unwind doesn't catch the panic.

@beepster4096
Copy link
Contributor Author

The uninit_write_slice_cloned_mid_panic test failed on wasm, probably because unwinding is not available and panic::catch_unwind doesn't catch the panic.

Do panics abort on wasm? Would #[cfg(panic = "unwind")] on the test fix it?

@m-ou-se
Copy link
Member

m-ou-se commented Dec 15, 2020

Yes. Looks like other tests are using that same cfg too, so that should be fine. (Some tests just explicitly ignore the wasm target for this reason, but those were written before cfg(panic = ..) existed.)

@beepster4096 beepster4096 force-pushed the maybe_uninit_write_slice branch from 5873f9f to 4652a13 Compare December 15, 2020 20:23
@m-ou-se
Copy link
Member

m-ou-se commented Dec 15, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Dec 15, 2020

📌 Commit 4652a13 has been approved by m-ou-se

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 15, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Dec 15, 2020
…, r=m-ou-se

MaybeUninit::copy/clone_from_slice

This PR adds 2 new methods to MaybeUninit under the feature of `maybe_uninit_write_slice`: `copy_from_slice` and `clone_from_slice`.

These are useful for initializing uninitialized buffers (such as the one returned by `Vec::spare_capacity_mut` for example) with initialized data.

The methods behave similarly to the methods on slices, but the destination is uninitialized and they return the destination slice as an initialized slice.
@bors
Copy link
Contributor

bors commented Dec 16, 2020

⌛ Testing commit 4652a13 with merge ddbc617...

@bors
Copy link
Contributor

bors commented Dec 16, 2020

☀️ Test successful - checks-actions
Approved by: m-ou-se
Pushing ddbc617 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 16, 2020
@bors bors merged commit ddbc617 into rust-lang:master Dec 16, 2020
@rustbot rustbot added this to the 1.50.0 milestone Dec 16, 2020

drop(src);

assert_eq!(Rc::strong_count(&rc), 2);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this test made Miri's run on the test suite fail, because it introduced a memory leak... can the test be adjusted to not leak memory?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the goal is just to test that Drop is not called, the better way is to use a type that panics on drop.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I confirmed that this function is the culprit, so I opened an issue: #80116

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@RalfJung Thanks for debugging this! I'll watch for leaks in tests more closely in future reviews. :)

@drmeepster Do you feel like changing it to a panic-on-drop to avoid the leak? Otherwise I can also make some time for this. ^^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-raw-pointers Area: raw pointers, MaybeUninit, NonNull merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.